Can you please add a code comment on why we need #nosec G107

I see your changes, thanks for adding them. I meant we should also add why are we ignoring G107. Something along the lines of "Since the URL is provided by the same user who wants to use the system and not by a third party, a malicious redirect will not be possible". ref https://securego.io/docs/rules/g107.html

We should do the same in other places as well.

isn't it obvious? :)

but actually, since we pass address as a command line parameter, it could be a security issue. But not for the fake cluster.

Considering the API is simple, instead of using structs, can we use functions as HTTP handlers? Please see https://www.alexedwards.net/blog/an-introduction-to-handlers-and-servemuxes-in-go (section "Functions as handlers")

I don't think we can use functions because I need to call eng from the handler.

Do we need some form of authn and authz? I think a user who is able to access the server will be able to privilege escalate since the user and the server use two different RBAC means. What are your thoughts on this?

I didn't want to complicate things. This is a local kind cluster, the nodes are virtual. I think authn/authz will be an overkill.

Yeah, fair point. Then we should add documentation describing the risks for users who want to have a long running cluster, maybe for simulation testing/QA.

I was also wondering; can we leverage the JWT tokens generated for Kubernetes service accounts? Use the tokens for a service account (https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount) for making calls to the Kubernetes API and let the Kubernetes API server handle auth. User will provide the token as a part of the Authorization header.